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Abstract 

O ', Community decisions about access control in virtual communities are non-monotonic in 

nature. This means that they cannot be expressed in current, monotonic trust management 
languages such as the family of Role Based Trust Management languages (RT). To solve 
this problem we propose RTq, which adds a restricted form of negation to the standard RT 
language, thus admitting a controlled form of non-monotonicity The semantics of RT Q 
is discussed and presented in terms of the well-founded semantics for Logic Programs. 
Finally we discuss how chain discovery can be accomplished for RT Q . 
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Languages from the family of Role Based Trust Management Framework (RT), 
like most Trust Management (TM) languages are monotonic: adding a creden- 
tial to the system can only result in the granting of additional privileges. Usually, 
this property is desirable in policy languages [24]. However, banishing negation 
from an access control language is not a realistic option. In fact, as stated by Li 
et al. [17] "many security policies are non-monotonic, or more easily specified as 
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non-monotonic ones"; similar views are expressed by Barker and Stuckey [2] and 
by Wang et al. [27] in the context of logic-based access control. This is also true 
for complex distributed systems such as virtual communities. In particular, as we 
will show, modelling access control decisions by a community, as opposed to ac- 
cess control decisions by an individual member, cannot be made without at least a 
form of negation, which we call negation-in-context. As pointed out by Dung and 
Thang [7] a TM system should be monotonic with respect to the credential submit- 
ted by the client but could be non-monotonic with respect to the site's local infor- 
mation about the client. Our extension allows a TM system to be non-monotonic 
not only in a local setting, but also when the context for negation can be provided. 

Contributions 

We present a significant enhancement to the power of the RT family of trust 
management languages by proposing RT e , an extension of RT . More specifically 
we: 

• add a single new statement type adding negation-in-context to standard RT; 

• present and discuss the declarative semantics of RT e ; 

• show that the extension is essential to specify access control policies for virtual 
communities. 

• describe a chain discovery algorithm for RT e . 

Currently, we are using RT e to specify and implement virtual community packages 
in the context of the Freehand project I-SHARE. In the next section we discuss 
how access control policies in virtual communities motivate us to add negation-in- 
context to RT. In Section 3 the syntax and informal semantics of RT e is introduced. 
The formal semantics of RT Q is presented in Section 4. We present related work in 
Section 7 and conclusions and future work in Section 8. 

2 Virtual Communities 

Virtual communities are groups of individuals with a shared interest, relationship or 
fantasy [16]. The majority of current virtual communities is interested in sharing 
audio/video content using P2P systems [22]. Taking into account the distributed 
nature of virtual communities, special mechanisms for access control must be pro- 
vided to ensure secure operations at both intra- and inter-community levels. As 
it is often impossible to identify strangers [21], trust must be established between 
community members and entities from outside the community prior to allowing a 
specific access. We adopt the solution of SPKI/SDSI [6], where cryptographic keys 
are identified instead of entities. This assumes that each entity is the sole holder of 
a particular key. As we do not want to impose a heavy PKI, the initial trust in a new 
key will be low, but this trust will increase over time (with good behaviour). 
As an example imagine that Alice (A), Bob (B), and Carol (C) decide to form a 
virtual community (or just a community for short). At the beginning they are the 
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only members of the community, but they welcome others to join. We represent a 
community by a list with an entry for each member. Each entry names the com- 
munity member and the members it knows about. This knowledge results from 
previous interactions with the community members. In this paper, however, when 
we say that one knows another community member we we mean that one is capable 
of finding this member later if necessary. Thus, the "knows" relation is not neces- 
sarily commutative, since one entity can decide to keep track of the other, but not 
vice versa. For example the following list represents the community of Alice, Bob, 
and Carol: 

A[B,C] B[A,C] C[A,B] 

In this community all members know each other, which means that each member 
can locate any other member when needed. As the community grows it becomes 
harder and harder for each member to have complete information about all other 
members. Yet the community would like to protect its integrity. Rather than to re- 
quire involvement of all members in decision making, a more practical and scalable 
approach is to allow decisions about membership to be taken by a group of coor- 
dinators selected from the community members. This group of coordinators itself 
forms a (sub)community. To find all the coordinators we require that the directed 
graph formed by the "knows" relation is strongly connected. This means that each 
coordinator has a relationship with at least one other coordinator in such a way 
that all coordinators can be reached. For example in the list below A knows B, B 
knows C and C knows B and A: 

A[B] B[C] C[B,A] 

To become a member of a community or to become a new coordinator all the exist- 
ing coordinators of a given community must approve. Trust management languages 
based on logic programming semantics do not support queries of this kind directly. 
If one wants to know "if all coordinators approve entity A" without explicitly enu- 
merating these coordinators, one must check if the negation of this statement - "is 
there any coordinator that does not approve entity A" - holds. If not, one can con- 
clude that all coordinators approve entity A. Existing trust management languages 
[18] are strictly monotonic, thus do not allow for negation. For this reason they are 
not sufficiently expressive to efficiently model complex collaborations that com- 
monly appear in virtual communities. 

Before we can elaborate on this using the example just presented, we need to review 
the definition of RT , and then present our extension RT Q . 



3.1 The RTq language 

RT contains two basic elements: entities and role names. Entities represent uniquely 
identified principals, individuals, processes, public keys, etc. Entities are denoted 
by names starting with an uppercase letter, for example: A, B, D, and Alice. A 
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role name begins with a lower case letter. In RT , roles are denoted by the en- 
tity name followed by the role name, separated by a dot. For instance A.r and 
Company. testers are roles. To define role membership, RT provides four kinds of 
policy statements: 

• A.r < — D (Simple Membership). Entity D is a member of the role A.r. 

• A.r < — B.ri (Simple Inclusion). Every member of B.ri is also a member of 
A.r. This represents delegation from entity A to entity B. 

• A.r < — A.r\.r 2 (Linking Inclusion). For every entity X who is a member of 
A.r i, every member of X.r 2 is also a member of A.r. This statement represents a 
delegation from entity A to all the members of the role A.T\. The right-hand side 
A.r\.r 2 is called a linked role. 

• A.r < — B\.r\ D B 2 .r 2 (Intersection Inclusion). Every entity which is a member 
of both B.ri and B.r 2 is a member of A.r. This statement represents partial del- 
egation from the entity A to B\ and to B 2 . The right-hand side B\.r\ fl B 2 .r 2 is 
called an intersection role. In a policy statement A.r < — e we call A.r the head 
and e the body. The set of policy statements having the same head A.r is called the 
definition of A.r. 

3.2 Extending RTq with negation 

RT and other languages from the RT framework do not support negation. As 
argued in Section 2, this limits expressiveness. Let us first see an example of nega- 
tion to enforce the following separation of concerns policy: "developers cannot be 
testers of their own code". We would like to express in RT something similar to the 
LP clause: 

verifycode(?A) :- tester(?A), not developer(?A). 

where ?A denotes a logical variable. This clause states that A can verify the code 
if A is a tester and A is not the developer responsible for the code. RT DT - another 
member of the RT framework [18] - supports thresholds and delegation of role 
activations; to some extent, RT DT allows to model separation of concerns without 
using negation. However, this comes at the cost of having to define manifold roles 
(cumbersome to work with, in practice). In any case, the examples we present in 
the sequel cannot be modelled in RT DT . We define a new type of statement based 
on RT and a new role-exclusion operator 0: 

• A.r < — Bi . r 1 B 2 . r 2 ( Exclusion ) All members of Bi . r i which are not members 
of B 2 .r 2 are added to A.r. 

Example Using the operator we can solve the separation of concerns problem as 
follows: 

Company. verifycode < — Company. tester Company. developer. (1) 



Suppose that both Alice and Bob are testers but Alice is also a developer of the 
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code: 

Company. tester « — Alice Company. tester < — Bob 
Company. developer < — Alice 

We see that credential 1 does not make Alice be a member of the 
Company. verifycode role. Thus, only Bob can verify the code. 

3.3 Modelling virtual communities using RT e 

Having given a simple example and its representation in RT e , we now return to the 
more complex scenario of community decision making from Section 2. 
Recall that we have a community of coordinators - Alice (A), Bob (£>), and Carol 
(C). Assume that another entity - say D - wants to join this community and asks 
Alice for approval. Alice can accept D as a new coordinator locally, but before 
making the final decision she must check if there is no objection from other coordi- 
nators. A coordinator expresses the objection using a so called black list. An entity 
that is on the black list of one of the coordinators will not be accepted as a new 
coordinator. 

Table 1 shows the minimal definition, and the descriptions of the roles used by 
coordinators. We see from Table 1 that some roles are mandatory while the others 
are not. For instance the role disagreeToAdd must be defined by each coordinator. 
On the other hand, the roles allCoord, allCandidates, and addCoord can be defined 
as needed by a coordinator. Special attention must be given to the definition of the 
disagreeToAdd role. For example, a coordinator can use the following credential to 
say that she distrusts any entity she does not accept locally: 

A. disagreeToAdd < — A. allCandidates AagreeToAdd. 

If a coordinator trusts other coordinators to select candidates she can leave the 
agreeToAdd role empty and use her disagreeToAdd role to block some candidates. 
For example, Alice can put E on her black list to disallow E to become a coordina- 
tor, and simultaneously accept all other candidates proposed by other coordinators: 

A. disagreeToAdd < — E. 

Table 2 shows the roles and their members as seen by Alice, Bob, and Carol. In 
this table, we assume that Alice agrees locally to add D as a new coordinator. Also, 
Bob and Carol have no objection to add D as a new coordinator, but E is on Alice's 
black list and F is on the black list of Bob and Carol. As a consequence, only D is 
the member of the addCoord role of Alice. Bob and Carol do not have to define the 
allCoord, allCandidates 9 , objectionToAdd, and addCoord unless they themselves 
add a new coordinator. 

9 A coordinator must define the allCandidates role if she defines the disagreeToAdd role in terms 
of the agreeToAdd role. 
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Table 1 
Roles used by coordinators 



Definition (for coordinator A) 


Description 


Op- 
tio- 
nal 


AagreeToAdd < — [set of entities] 


A coordinator uses this role to express that she 
approves an entity. The role has a local mean- 
ing. It is not sufficient to be a member of the 
agreeToAdd role to become a coordinator. It 
is necessary that no other coordinators says 
that an entity is a member of her disagree- 

A si W i 1 T^ri£> / j 1 1 i-ji ji ijr-t A A A xt\\ t ntr\j l ly n t ri^t 
lUf\LlLl 1U1C 1 11C Ltg 1 ee lUf\LlLl 1U1C, LlllUUgll L11C 

allCandidates role, provides context for the 
operator in the definition of the the addCoord 
role. 




AdisagreeToAdd < — 

[see description in the text] 


This role is used by a coordinator as a black 
list. 




Acoord < — [set of entities] 


This role contains all the coordinators known 
by a coordinator. 




AallCoord < — A 

AallCoord < — AallCoord. coord 


This role allows a coordinator to iterate over 

■all £»ttti ti pnnnpptpn n\/ tr>£» rr\ r\ f/~J 1 l^nic 
all CllLlLlCo Uy L11C CUUfU 1U1C 1 Ills 

role, if defined, contains all the coordinators. 


j 

V 


AobjectionToAdd < — 

AallCoord. disagreeTo Add 


A coordinator can use this role to obtain all 

pntitiPQ for whi thprp iq any ohifption 

CllLlLlCd 1VJ1 Wlll^Il L11C1C lO tlllV VJUJC^LlVJll. 


/ 


AallCandidates < — 

A . allCoord . agreeTo Add 


This role, if defined, contains all the candi- 
date coordinators locally accepted by any of 
the coordinators. Used as the context for the 
operator in the body of the addCoord role. 


/ 


AaddCoord < — AallCandidates 
AobjectionToAdd 


After becoming a member of this role, a can- 
didate coordinator becomes a new coordinator 
and becomes a member of the coord role. 


/ 



4 Semantics 



The semantics of trust management languages is typically given by a translation 
into Logic Programming (LP) [18]. We will follow the same route. Trust man- 
agement credentials are by definition distributed among different principals. The 
use of negation creates an additional difficulty, also because in logic programming 
various different semantics exist to cope with negation. We have chosen to use 
the Weil-Founded (WF) semantics [10] for the reasons sketched below. The WF 
semantics imposes no restrictions on the syntax of programs, provides an unique 
model for each program (as opposed to e.g. the stable model semantics [11]) and 
enjoys an elegant fixed-point construction. 

The WF semantics basically works as follows (we refer the interested reader 
to [10] for details): For a program, consisting of a set of rules, one iteratively 
builds positive and negative facts. Positive facts are obtained as usual; any fact 
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Table 2 

Adding a new coordinator - D is successful, E, F fail (ND = Not Denned) 





coord 


agreeToAdd 


allCoord 


allCandidates 


disagreeToAdd 


obj ectionTo Add 


addCoord 


Alice (A) 


{B} 


{D} 


{A,B,C} 


{D} 


{E} 


{E,F} 


{D} 


Bob (B) 


{C} 


{} 


ND 


ND 


{F} 


ND 


ND 


Carol (C) 


{B,A} 


{} 


ND 


ND 


{F} 


ND 


ND 



that can be derived by a rule from the already found facts is added. Negative facts 
are obtained from 'unfounded sets' which contain currently undecided facts which 
no rule can derived even when the elements of this set are set from undecided to 
false. Thus setting this unfounded set to false will not create contradictions. As we 
cannot always obtain a positive or negative version of each fact, some atoms will 
remain undecided and be assigned the value 'undefined', i.e. the WF semantics is 
three valued. 

In a TM system it is impossible to avoid circular references, and we cannot ex- 
pect policies to be (locally) stratified. Stratification basically means that one can 
restructure a logic program into separate parts in such a way that negative refer- 
ences from one part refer only to previously defined parts. Without the possibility 
of local stratification we cannot refer to the perfect model semantics [23]. For the 
same reason, we certainly have to refer to a three valued semantics: Next to the 
truth values true and false, we have to admit the valued undefined. In short, this 
is because we cannot expect the completion of a policy to be a consistent logic 
program in the sense described in [25]. 

The handling of positive circular references, as in {A.r < — B.r B.r < — 
A.r} should be done in accordance with the semantics of RT ; we should obtain 
that some entities, for example C, do not belong to A.r. This forces us to exclude 
Kunen's semantics [15] (i.e. the semantics of logical consequences of the com- 
pletion of the program together with the weak domain closure assumptions), and 
Fitting's semantics [9]: in both semantics the query "does C belong to Ar?" would 
return undefined. The WF semantics does return false for this membership query. 

Example 4.1 Consider the program V with the following clauses: 

p :- q. q :- p. r :- -iq. s :- ~^t. t :- -is. u :- -is. 

In the well-founded model of V we have that p and q are false, r is true and s, t, and 
u are undefined. (On the other hand, all predicates would be undefined in Kunen's 
semantics.) 
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4. 1 Translating RT e to GLP 

We first give the translation to LP for RT and, using this translation, the semantics 
of a set of RT policy statements. Next we extend this to a translation from RT e to 
GLP and the semantics for a set of RT e policy statements. 

The semantics of a set of RT policy statements is commonly defined by translating 
it into a logic program [18]. Here, we depart from the approach of Li et al. [18] by 
referring to the role names as predicate symbols. The statement A.r < — D is, for 
example, translated to r(A, D) in the Prolog program. Intuitively, r(A, D) means 
that D is a member of the role A.r. 

Definition 4.2 Given a set V of RT policy statements, the semantic program, 
SP(V), for V is the logic program defined as follows (recall that symbols start- 
ing with "?" represent logical variables): 

• For each A.r < — D E V add to SP(V) the clause r(A, D) 

• For each A.r < — B.n E V add to SP(V) the clause r(A, 1Z) :- n(B, 1Z) 

• For each A.r < — A.r x .r 2 GPaddto SP(V) the clause r( A, 1Z) :-n(A,?Y), 
r 2 (?F,?Z) 

• For each A.r < — B 1 .r 1 n B 2 .r 2 E V add to SP(V) the clause r(A, ?Z) :- 
r 1 (B 1 ,?Z),r 2 (B 2 ,?Z) 

The semantics of a role A.r is a set of members Z that make the predicate r(A, Z) 
true in the semantic program: [Ar]p = {Z \ SP(V) |= r(A, Z)} 

We write SP(P) \= r(A, Z) if r(A, Z) is true in the unique well-founded model of 
P. (For negation-free programs this model coincides with the least Herbrand model 
used for the semantics of RT by Li at al [18].) We now extend the translation of 
RT to that of RT e by adding the translation of the exclusion rule. 

Definition 4.3 Given a set V of RT e policy statements, the semantic program, 
SP(V), for V is the general logic program defined as follows: 

• For each A.r < — B.r x B.r 2 E V add to SP(V) the clause r(A, 1Z) :- 
r x {B u lZ)^r 2 {B 2 ,lZ) 

• All other rules are as in definition 4.2. 

The semantics of a role A.r is a set of members Z that make the predicate r(A, Z) 
true in the semantic program: [Ar]-p = {Z \ SP(V) |= r(A, Z)} 

Note that, unlike before, the value of the semantical program may give value 'un- 
defined' for r(A, Z). In this case the agent Z is not considered to be a member of 
the role, nor of the negated role. 

Example 4.4 Consider a system with entities A, B, C, D, roles A.r, B.r and C.r 
and the following policy rules: 

A.r < — B.r C.r C.r < — B.r A.r B.r < — D 

Here D is a member of B.r, however, D is not a member of either A.r or C.r. Note 
that as a result we have that despite the presence of the rule A.r < — B.r C.r the 
role B.r can have members that are neither in A.r nor in C.r. 
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The rules for A.r and C.r in the example above are referred to as negative circular 
dependencies; A.r depends negatively on C.r and C.r, in turn, depends negatively 
on A.r. The example shows that care is required when reasoning about policies 
which have negative circular dependencies. 

4.2 Virtual Communities - translation to GLP 

Having introduced an example of virtual community decision making in Section 2, 
its formalism in Subsection 3.3, we now give the GLP semantics of the example. 
Translating RT e credentials to GLP is straightforward using the rules presented in 
Subsection 4.1. For the convenience of the reader we present a complete policy 
and the corresponding GLP rules in Appendix A. If one asks Alice to add D to 
the group of coordinators she needs to check if D is a member of the A.addCoord. 
This is equivalent to checking whether addCoord(A,D) holds after the translation to 
GLP. She does this by checking whether D is a logical consequence of the semantic 
program SP(V) by first finding the semantics of the role A.addCoord and checking 
if it contains entity D. The semantics of the role A.addCoord with respect to the 
program V is as follows: 

[AaddCoordJp = {D}. 

The semantics of the roles A.allCandidates and A.objectionToAdd (these roles de- 
fine the volt A.addCoord) are shown below: 

[AallCandidates] P = {D} [AobjectionToAdd] P = {E, F}. 

The semantics of a role may also be an empty set: [S.agreeToAddJ-p = {}. 

5 Credential Chain Discovery 

In this section we extend the standard chain discovery algorithm to RT Q following 
the construction of the well-founded semantics. Recall that the definition of a role 
A.r is the set of all credentials with head A.r. We assume that A stores (or at 
least, is able to find) the complete definition of each of her roles A.r, i.e. that the 
credentials involved are issuer-traceable. The main difficulty in the chain discovery 
is to obtain that B is not a member of a linked role A.r.r'. For this we need to check 
that every potential member C of A.r does not have B in its role C.r' . So who are 
the potential members of Ar? Thanks to negation in context we can provide a 
reasonable overestimation of this set using chain discovery for RT : 

Definition 5.1 For a policy V the context policy V+ is the policy obtained by 
replacing each credential of the form A r < — Bi.riQB 2 .r 2 E V by A.r < — B^xi 
and leaving the other credentials unchanged. We call [Ar]-p + the context of the 
role A.r. 

The following lemma relates roles with their contexts. 
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Lemma 5.2 For any policy V and role A.r we have: If SP(V) \= r(A, B) then 
SP(V+) |= r(A, B) and ifSP(V+) ^ r{A, B) then SP(V) |= ->r(A, B). 

The first part of this lemma states that any role is contained in its context, [Ar]-p C 
[Ar] P+ . If B g [A.r\ v this means that r(A, B) is undefined or false in SP(V). 
The second part of the lemma states that if B G" {A.r]-p + it must be the latter, 
r(A, B) is false in SP(V). In the algorithm below we build a set of credentials 
C together with a set of context membership facts X+ and a set of positive and 
negative membership facts X. 

Step 1. Initialise X = 0, X+ = and C = the definition of role A.r. 
Step 2. Discover context and credentials (classical chain discovery for X+ and C). 
We look for new credentials top down; any credential that could possibly be rel- 
evant for role A.r is added to C. We look for the context of A.r bottom up; any 
fact that can be derived from the credentials that we have found is added to X+. 
Repeat the following until no changes occur: For each credential of the following 
form in C: 

[fi.r < — C] add r (fi, C) to X+ 

[fi.r < — C.ri] add the definition of C.ri to C and add r (fi, D) to X+ for all 
n(C,D) inX+ 

[fi.r < — C\.r\ fl C 2 .r 2 ] add the definitions of C\.T\ and C 2 .r 2 to C add 
r (fi, D) to X+ whenever ri(d, D) and r 2 (C 2 , D) in X+. 

[B.r < — C.r 1 .r 2 ] add the definition of C.ri and, for each r^C, D) E X+, 
the definition of D.r 2 to C. Add r (_B, D) to X+ whenever for some Y we have 
t x {C,Y) and r 2 (Y,D) inX+. 

[B.r < — C\.r\ C 2 .r 2 ] add the definitions of C\.T\ and C 2 .r 2 to C, add 
r (B, D) to X+ for every r^Ct, D) 

Step 3. Discover positive facts in X (extended chain discovery 1). 
We update X similar to X+ in the previous step, only the last case (0) changes. 
Repeat until X does not change, for credentials in C of the following form: 
[fi.r < — C] add r (fi, C) to X 

[fi.r i — C.ri] add r (fi, fi) to X for all n(C, fi) in X 
[fi.r < — Ci. ri n C 2 .r 2 ] add r (B,D) to X whenever r^Ci.fi) and r 2 (C 2 ,D) 
in X. 

[fi.r < — C.ri.r 2 ] Add r (fi, fi) to X whenever for some Y we have ri(C, Y) 
and r 2 (l", fi) in X. 

[fi.r < — Ci.ri C 2 .r 2 ] add r (fi,fi) to X whenever ri(Ci,fi) G X and 
either (-r 2 (C 2 , fi)) G X or r 2 (C 2 , fi) X+. 
Step 4. Discover negative facts in X (extended chain discovery 2). 
We search for facts which are useful when negated in X: Initialise hi = 0. We say an 
atom r(X, Y) is not yet false (NYF) if it is a member of the context and not assumed 
or known to be false, i.e. r(X, Y) G X+, r(X, Y) and Y) ^ X. A fact 

r 2 (C 2 , fi) is useful if it is not yet false and -■r 2 (C 2 , D) can be used to derive a fact, 
i.e. fi.r < — Ci.ri C 2 .r 2 G C and ri(Ci, fi) G X. Choose one useful fact and 
add it to U. 
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Next we try to show that facts in U are false by showing that no rule can possibly 
derive a fact in hi. To achieve this we may need to assume that other facts are also 
false, i.e. add them to hi. 

For each fact r(B, D) in hi and matching rule B.r < — e E C perform: 
[B.r < — C] Do nothing. 

[B.r < — C.ri] This rule cannot be used to derive r(B, D) if r^C, D) is false 
thus if n(C, D) is NYF then add it to U. 

[B.r < — d.ri n C 2 .r 2 ] If n(Ci, D) and r 2 (C 2 , D) are both NYF then choose 
one to add to hi. 

[B.r < — Ci.ri C 2 .r 2 ] If r^C^D) is NYF and r 2 (C 2 ,D) £ X then add 
n{C u D) toU. 

[B.r < — Cn.r 2 ] For all Y with n(C, Y) NYF: If r 2 (Y, D) is NYF choose 
one of ri(C, Y) and r 2 (Y, D) and add it to hi. 

* Try each possible choice in the substep above and if the resulting hi has no 
elements in common with X then add -i hi to X. 
Repeat steps 3 and 4 until X remains unchanged. 

(End of algorithm.) The algorithm correctly finds the members of the role A.r: 

Vfi : r(A, B) el ^ B e [A.r] v 

It follows the steps in the construction of the well-founded semantics in such a way 
that X is, at each stage, a sufficiently large subset of the well-founded model. 

6 Implementation 

In the current prototype storage is centralised and we assume that all credentials 
can be traced by the issuer. In such a case, Linear resolution with Selection func- 
tion for General logic programs (SLG) resolution of XSB prolog can be used to 
compute answers to queries according to the WF model for RT e [5]. XSB is 
a research-oriented, commercial-grade Logic Programming system for Unix and 
Windows-based platforms. XSB provides standard prolog functionality but also 
supports negations and constraints. Using SLG resolution XSB prolog can cor- 
rectly answer queries for which standard prolog gets lost in an infinite branch of a 
search tree, where it may loop infinitely. A number of interfaces to other software 
systems including Java and ODBC are available. DLV datalog [8] and the Smod- 
els system [20] can also be used to provide an initial implementation of RT e . The 
DLV system [8] is a system for disjunctive logic programs. It is distributed as a 
command line tool for both Windows and Linux operation systems. DLV is capa- 
ble of dealing with disjunctive logic programs without function symbols allowing 
for strong negations, constraints and queries. DLV uses two different notions of 
negation: negation as failure and true (or explicit) negation. By default, DLV han- 
dles negation as failure by constructing the stable model semantics for the program. 
This standard behaviour can be changed using a command line option and then a 
WF model is built instead. The true or explicit negation expresses the facts that 
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explicitly are known to be false. On the contrary, negation as failure does not sup- 
port explicit assertion of falsity. Models of programs containing true negation are 
also called "answer sets". The Smodels system [20] provides an implementation of 
the well-founded and stable model semantics for range-restricted function-free nor- 
mal programs. The Smodels system allows for efficient handling of non- stratified 
ground programs and supports extensions including built-in functions, cardinality, 
and weight constraints. The Smodels system is available either as a C++ library 
that can be called from user programs or as a stand-alone program with default 
front-end (Iparse). We implemented the program introduced in sub- section 4.3 on 
three systems: XSB, Smodels and DLV. To test the performance of the program 
on these systems, we use two parameters: number of coordinators (Coords) and 
number of iterations (Iters). The higher the number of coordinators is, the more 
complex the program is. The program is also executed repeatedly to compare per- 
formance more correctly. Table A. 2 in the appendix reports the execution time of 
the program measured by the CPU time obtained. We cannot compare the execu- 
tion time between XSB and the other two DLV and Smodels because XSB is the 
goal-oriented system while DLV and Smodels build and return the whole model 
for the program. Because of this XSB is faster than the other two systems. DLV 
provides better execution time than Smodels, especially when the complexity of the 
program increases. 

7 Related Work 

So far little attention has been given to trust management in virtual communities. 
Most of the existing approaches focus on reputation-based trust models in P2P net- 
works [26]. Abdul-Rahman and Hailes [1] propose a trust model that is based 
on real world social trust characteristics. They also find formal logic based trust 
management to be ill suited as a general model of trust. To prove this claim they 
refer to the early work of Burrows and Abadi [4], and Gong, Needham, and Ya- 
halom [12], which are more relevant to formal protocol verification than to formal 
reasoning on trust management. To support their work they claim that logic based 
trust management systems are not suitable to be automated - the existing literature 
on automated trust negotiation (ATN) yields a contradictory statement (see Sea- 
mons et al. [24]). Pearlman et al. [21] present a Community Authorisation Service 
- a central management unit for a community that helps to enforce the policy of a 
virtual community. Such a central point of responsibility does not fit well in the 
spirit of P2P networks because of their highly distributed nature. Pearlman et al. 
also require that there a centralised policy exists for a virtual community. How- 
ever, the policy of a virtual community may have a distributed character and can 
be seen as a product of the policies of the community members. Boella and van 
der Torre [3] take the same direction and emphasise the distinction between autho- 
risations given by the Community Authorisation Service and permissions granted 
by resource providers in virtual communities of agents. They regard authorisation 
as a means used by community authorities to regulate the access of customers to 
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resources that are not under control of these authorities. According to Boella and 
van der Torre, permission can be granted only by the actual resource owner. 

As we conclude in Section 2, virtual communities are also not supported by 
the existing trust management languages, even though the general requirements for 
such languages have been investigated [24]. 

Herzberg et al. propose in [13] a prolog-based trust management language 
(DTPL) together with a non-monotonic version of it (TPL). Their approach is very 
different from ours in the sense that TLP allows for negative certificates namely 
"certificates which are interpreted as suggestions not to trust a user". This far- 
reaching approach leads to a more complex logical interpretation, which includes 
conflict resolution. As opposed to this, our approach is technically simpler and 
enjoys a well-established semantics. Jajodia et al. [14], Wang et al. [27], Barker 
and Stuckey [2], have in common that they impose a stratified use of negation. Be- 
cause of this, they can refer to the perfect model semantics. As we explained in 
Section 4, in the context of DTM, we cannot expect policies to be stratified. Our 
approach is thus more powerful than the approaches based on the stratifiable nega- 
tion. Dung and Thang in [7] propose a DTM system based on logic programming 
and the stable model semantics [11]. 

8 Conclusions and future work 

We present the language RT e , which adds a construct for 'negation-in-context' to 
the/? To trust management system. We argue the necessity of such a construct and il- 
lustrate its use with scenarios from virtual communities which cannot be expressed 
within the RT framework. 

We provide a semantics for RT e by translation to general logic programs. We 
show that, given the complete policy, the membership relation can be decided by 
running the translation in systems such as XSB, DLV datalog and Smodels. We 
also show how, for the case that credentials are issuer traceable [19], the chain 
discovery algorithm for RT can be extended to RT e . We are currently employing 
RT e to specify virtual community policies in the Freehand project I-SHARE. In the 
future we plan to examine the complexity of the presented chain discovery algo- 
rithm, ad hoc methods to minimise communication overhead, and safe methods for 
chain discovery in non- 'issuer traces all' scenarios. A comparison with reputation 
systems will also be made. 

In section 5 we have assumed that the credentials are issuer traceable and that 
we are able to obtain all relevant credentials. In our scenario this is realistic; as 
the coordinators play a central role, they are generally assumed to be available 
sufficiently often and have sufficient resources to store their own credentials. In 
general collecting all credentials can be difficult, for example, credentials may be 
stored elsewhere, entities may be unreachable or messages may be lost. In such 
a situation, we cannot safely determine that A is not in B's role r by absence of 
credentials. Instead we could ask B to explicitly state that A is not a member of 
B.r. This is sufficient if we know the context of a role (and thus which negative 
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facts we need). More advanced mechanisms to guarantee safety of roles and a 
precise definition of which policies are safe using which mechanism is subject of 
further research. 



References 

[1] A. Abdul-Rahman and S. Hailes. Supporting trust in virtual communities. In HICSS 
'00: Proc. of the 33rd Hawaii International Conference on System Sciences-Volume 6, 
page 6007. IEEE Computer Society Press, 2000. 

[2] S. Barker and P. J. Stuckey. Flexible access control policy specification with constraint 
logic programming. ACM Trans, on Information and System Security, 6(4):501-546, 
2003. 

[3] G. Boella and L. van der Tone. Permission and authorization in policies for 
virtual communities of agents. In Proc. of Agents and P2P Computing Workshop 
at AAMAS'04. Springer Verlag, 2004. 

[4] M. Buitows, M. Abadi, and R. Needham. A logic of authentication. ACM 
Transactions on Computer Systems, 8(1):18— 36, 1990. 

[5] W. Chen, T. Swift, and D.S. Warren. Efficient top-down computation of queries under 
the well-founded semantics. Journal of Logic Programming, 24(3): 161-199, 1995. 

[6] D. Clarke, J.E. Elien, C. Ellison, M. Fredette, A. Morcos, and R. L. Rivest. Certificate 
chain discovery in SPKI/SDSI. Journal of Computer Security, 9(4):285-322, 2001. 

[7] P.M. Dung and P.M. Thang. Trust Negotiation with Nonmonotonic Access Policies. 
In Proc. IFIP International Conference on Intelligence in Communication Systems 
(INTELLCOMM 04), volume 3283 of LNCS, pages 70-84. Springer- Verlag, 2004. 

[8] T. Eiter, W. Faber, N. Leone, and G. Pfeifer. Declarative problem-solving using the 
DLV system, pages 79-103, 2000. 

[9] M. Fitting. A Kripke-Kleene semantics for Logic Programs. Journal of Logic 
Programming, 2(4):295-312, 1985. 

[10] A.V. Gelder, K.A. Ross, and J.S. Schlipf. The well-founded semantics for general 
logic programs. Journal of ACM, 38(3):620-650, 1991. 

[11] M. Gelfond and V. Lifschitz. The Stable Model Semantics For Logic Programming. 
In Proc. 5th International Conference on Logic Programming, pages 1070-1080. MIT 
Press, 1988. 

[12] L. Gong, R. Needham, and R. Yahalom. Reasoning About Belief in Cryptographic 
Protocols. In Proceedings 1990 IEEE Symposium on Research in Security and 
Privacy, pages 234-248. IEEE Computer Society Press, 1990. 

[13] A. Herzberg, Y. Mass, J. Michaeli, Y. Ravid, and D. Naor. Access Control Meets 
Public Key Infrastructure, Or: Assigning Roles to Strangers. In Proc. 2000 IEEE 
Symposium on Security and Privacy (S&P 2000), pages 2-14, Oakland, CA, 2000. 
IEEE Computer Society Press. 

14 



Czenko, Tran, Doumen, Etalle, Hartel, den Hartog 



[14] S. Jajodia, P. Samarati, M.L. Sapino, and V.S. Subrahmanian. Flexible support for 
Multiple Access Control Policies. ACM Transactions on Database Systems (TODS), 
26(2) :2 14-260, 2001. 

[15] K. Kunen. Negation in Logic Programming. Journal of Logic Programming, 
4(4):289-308, 1987. 

[16] F. Lee, D. Vogel, and M. Limayem. Adoption of informatics to support virtual 
communities. In HICSS '02: Proc. of the 35th Annual Hawaii International 
Conference on System Sciences (HICSS'02)-Volume 8, page 214.2. IEEE Computer 
Society Press, 2002. 

[17] N. Li, J. Feigenbaum, and B. N. Grosof. A Logic -based Knowledge Representation 
for Authorization with Delegation (Extended Abstract). In Proc. 1999 IEEE Computer 
Security Foundations Workshop, pages 162-174. IEEE Computer Society Press, June 
1999. 

[18] N. Li, J. Mitchell, and W. Winsborough. Design of A Role-based Trust-management 
Framework. In Proc. 2002 IEEE Symposium on Security and Privacy, pages 1 14-130. 
IEEE Computer Society Press, May 2002. 

[19] N. Li, W. Winsborough, and J. Mitchell. Distributed Credential Chain Discovery in 
Trust Management. Journal of Computer Security, 1 1(1):35— 86, 2003. 

[20] I. Niemel and P. Simons. Smodels - an implementation of the stable model and well- 
founded semantics for normal lp. In LPNMR '97: Proc. of the 4th International 
Conference on Logic Programming and Nonmonotonic Reasoning, pages 42 1-430. 
Springer- Verlag, 1997. 

[21] L. Pearlman, V. Welch, I. T. Foster, C. Kesselman, and S. Tuecke. A community 
authorization service for group collaboration. In POLICY, pages 50-59. IEEE 
Computer Society Press, 2002. 

[22] J.A. Pouwelse, P. Garbacki, D.H.J. Epema, and H.J. Sips. The Bittorrent P2P File- 
sharing System: Measurements and Analysis. In Proc. of the 4th International 
Workshop on Peer-to-Peer Systems (IPTPS05), February 2005. 

[23] T. C. Przymusinski. Perfect model semantics. In Fifth international Conference and 
Symposium on Logic programming, Seattle, U.S.A., pages 1081-1096. MIT Press, 
1988. 

[24] K. E. Seamons, M. Winslett, T. Yu, B. Smith, E. Child, J. Jacobson, H. Mills, and 
L. Yu. Requirements for Policy Languages for Trust Negotiation. In Proc. 3rd 
International Workshop on Policies for Distributed Systems and Networks (POLICY 
2002), pages 68-80. IEEE Computer Society Press, 2002. 

[25] J. C. Shepherdson. Negation in Logic Programming. In Foundation of Deductive 
Databases and Logic Programming, pages 19-88. Morgan Kaufmann, 1988. 

[26] V. Shmatikov and C. L. Talcott. Reputation-based trust management. Journal of 
Computer Security, 13(1): 167-190, 2005. 

15 



Czenko, Tran, Doumen, Etalle, Hartel, den Hartog 

[27] L. Wang, D. Wijesekera, and S. Jajodia. A logic -based framework for attribute 
based access control. In Proc. 2004 ACM workshop on Formal methods in security 
engineering FMSE'04, pages 45-55. ACM Press, 2004. 

Appendix A 



Table A.l 

Virtual Community - translation to GLP 



RT e rules 


GLP semantics 


A 1 i(H 1 A 11 1" 1 * > — , 

AaddCoord < — AallCandidates 


1 1 1 / A OT/'\ 11 1*1 i (A OT/"\ 

addCoord(A, TY ):- allCandidates(A, "Y), 


A . objectionTo Add 


-•objection loAdd( A 'Y ). 


AallCandidates < — 


allCandidates(A !Y ):- allCoord(A (Z), 


A .11 /~i j „ T"' A J J 

A allCoord. agree lo Add 


agree toAdd( <Z, CY). 


AobjectionToAdd < — 


objection IoAdd( A (Y ):- allCoord(/i, :ZJ, 


AallCoord. disagreeToAdd 


disagreeToAdd(?Z, ?Y). 


AdisagreeToAdd < — AallCandidates 


disagreeToAdd(A, ?Y):- allCandidates(A, 


AagreeToAdd 


-■agreeToAdd(A,?Y). 


AallCoord < — AallCoord. coord 


allCoord(A, ?Y):- allCoord(A, ?Z), 




coord(?Z, ?Y). 


AallCoord < — A 


allCoord(A, A). 


A coord « — B 


coord(A, B). 


B. coord < — C 


coord(B,C). 


C. coord < — B 


coord(C,B). 


C. coord < — A 


coord(C, A). 


AagreeToAdd < — D 


agreeToAdd(A,L>). 


AdisagreeToAdd < — E 


disagreeToAdd(A S). 


B. disagreeToAdd < — F 


disagreeToAdd(B, F). 


C.disagreeToAdd < — F 


disagreeToAdd(C, F). 



Table A.2 

Execution time of the program on the XSB, SMODELS, and DLV systems 





10 Coords 


30 Coords 


50 Coords 




Num. of Iterations 


Num. of Iterations 


Num. of Iterations 




1 


10 


20 


1 


10 


20 


1 


10 


20 


DLV 


0.05s 


0.81s 


1.54s 


0.06s 


0.83s 


1.55s 


0.07s 


0.86s 


1.60s 


SMODELS 


0.12s 


1.22s 


2.32s 


0.16s 


1.35s 


2.66s 


0.19s 


1.53s 


2.94s 


XSB 


«0 
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